BioShock MMORPG Programming
Sitemap BioShock MMORPG Programming Issues --- --- --- --- --- Technical/Hardware issues for game - Game Engine features required/expected : Can the expected hardware (especially for likely console's) support many of the following : * Non-clumsy input interfaces (ex- tedious menu-itus of console controllers...) * More versatile NPC figures holding/manipulating Objects (a little more than the standard gun pose with a limited list of weapons), many more NPC animations... Vehicles... * Client-side building of render Assets via parameterized Templates - substitution textures, combination sub-Objects(conglomerations) will cut down/compresses the network data sent to Clients (bandwidth issues will ALLWAYS be with us). * Client Preloading/caching of Assets before they are need for rendering/output (position/activity data from Server and most definition data from local disk ). * Physics support (at least rudimentary .. platforms??) but now will a magnitude more interacting objects work out? Ragdoll/projectile physics seen in BS1/BS2 was adequate. * Native language coding for faster logic execution (and for secondary AI Servers) Possibly JIT from bytecode (multiple platform issues will always be with us - to make this hard to do systematically). * Compiled scripts (byte code versus interpreted scripting) with fragment loading for behavior scripting. Bytecode with a VM (Virtual Machine) allows easier multi-platform (note- Tablet/Smartphone variations adds yet more platforms) - Denser script 'data' as there will be alot of load-on-the-fly between Server and Clients, which will run alot of the simulation's visual effects (and hopefully NPC AI stuff) * Tablet/Handheld systems do not have to be 3D (for most part or many of them (smartphones) wont be powerful enough) - 'Client' tablet computer operations may use partial/simplified (lower processing) Game Engine features (might make difference for 3D map interface used for 'offline' 'Team' task assignments). Tablets/handhelds will always be less capable than desktop systems - yet will be important aspect of this MMORPG. * Console platform capacity/capabilities may be overwhelmed (especially with infrequent new generation of more powerful models in widespread use/possession by Players). Dumbing-down some features - will require more work to achieve game 'working adequately' for various older flavors of consoles. Many advanced features/Player experiences which count on greater computer machine abilities would be thwarted. Simple lack of sufficient local 'disk' storage could be a killer (Gigs and Gigs of cached data). * Object-based architecture/terrain, much more than previous games (non-static persistent 'deformable' terrain, instancing bubbles, 'on-the-fly' generation/integrations). A generalized mechanisms rather than the usual limited hand-built/local-scripting/choreographed/canned/static content. * A much more alive/interactive world than the existing crop of fossilized/''ante-bellum'' MMORPGs. Versatile placement and locking down of 'owned' Objects. Periodic script 'behavior' execution for 'active' Objects (now large numbers of them everywhere -- no objects are just 'part of the scenery' inert). * MMORPG Server Component (Solo and MP games don't have this problem). Communication bandwidth alone is a major challenge. Interactions between multiple Players and the multitudes of NPCs, greatly increases the 'bookkeeping' processing and updating required. Use Cluster processing servers with load leveling to make best use of processing resources (which are significantly more than in existing MMORPGs). - Advanced : * Asset Atlas/Dictionary used on the Client end. Disk storage of Assets allowing regular patching and on-the-fly 'as needed' new data loading (newly published objects being added all the time and auto-expanding world system). SSD (Solid State Disk) drives definitely will help with loading data once it gets into the Client machines 'Dictionary'... Once pulled from Server it becomes local data on disk for faster 'next-time' use. Various streaming data schemes can be used for this real-time, and will be helped by the future expanding data bandwidths. * Client-side AI for Player's "Team" subset of NPCs (including optional/customized scripting modules) to offload from Servers and have hundred-fold increase of AI capacity . Assisting the Simulation by farming out AI processing might also be possible -- all the mundane 'filler' activity stuff that NPCs do when you are around (and it being much better mundane behavior as well). * Voice Input - would improve control especially of NPC 'Team' Activities (really more activation of pre-arranged tactics/activity modes that otherwise requires slow menu options interface.) No fancy human talking more along the lines of single-word short-phrase activations (trying to avoid 'too many keys' syndrome many games are getting). - Fortunately computer capacities advance : * more CPU, more multiprocessing * more/faster Memory * better GPUs * faster/larger 'Disk' storage * higher network bandwidths (though probably not better latency) --- --- --- Why Do Many Original BioShock Level Maps Have Defects : * The level designers did not bother to test/review their design (and if detected too late and major changes were required it was too much work). * Interfaces between maps (elevator facings, building overlaps) are contradictory because many are made by different developers. * Because they are designed for the VISUAL interior spaces (cosmetic) and anything indirectly viewed is just incidental (ex- the paper thin walls in many places which are irrelevant to the Players actions). * Outside views are of less than secondary importance (they dont affect the played game). The MMORPGs would use Templates - standard componentized construction (where the template components can be thoroughly tested and then reused). They would be designed to be correct in all details. There would be Autotest (programatic tetsing) features to verify requirements are met in their placement and other situational factors. --- --- --- --- --- . .